iT邦幫忙

code smell相關文章
共有 27 則文章

技術 Other Smell > Incomplete Library Class 不完美的外部套件與重構

前言 今天是第三十六天,這也是本系列介紹的最後一個程式碼氣味。明天總結出新版本的氣味對照重構表後,終於可以完成這次的鐵人賽挑戰。昨天剛巧看見龍哥分享資深工程師身...

技術 Dispensables > Oddball Solution 歧異解方與重構

氣味的徵兆 當你在專案內的不同地方發現存在實現相同功能,但卻是不同實作細節的程式碼片段,這種現象可被稱為「歧異解方(Oddball Solution)」氣味,或...

技術 Couplers > Indecent Exposure 過度揭露與重構

氣味的徵兆 當我們發現類別或方法毫無節操的對外洩漏內部實作細節時,我們可能發現了「過度揭露」氣味(Indecent Exposure or Excessive...

技術 Change Preventers > Combinatorial Explosion 組合爆發與重構

氣味的徵兆 這個程式碼氣味發生在多個程式碼片段執行「幾乎相同」的任務,但卻使用了不同的資料或行為組合。請特別留意「幾乎相同」而不是真正完全相同。 如果當你注意到...

技術 Couplers > Middle Man 中間人與重構

氣味的徵兆 如果一個類別除了當作另外一個類別的中間通道之外,沒有提供更多額外的價值,我們可以稱呼這種情況為「中間人(Middle Man)」氣味。物件導向中一個...

技術 Couplers > Message Chains 訊息鏈與重構

氣味的徵兆 訊息鏈(Message Chains)又被稱為「火車殘骸(Train Wrecks)」,當我們執行方法時會需要呼叫一個物件,然後該物件又需要呼叫另外...

鐵人賽 Software Development DAY 30

技術 Couplers > Inappropriate Intimacy 不當親密類別與如何重構

氣味的徵兆 Inappropriate是不當、不妥的意思,Intimacy則是親密之意,兩個字合起來可以直接翻譯為「不當的親密關係」。中文版的「Refactor...

鐵人賽 Software Development DAY 29

技術 Couplers > Feature Envy 依戀情節與重構

氣味的徵兆 當一個方法過於貪心不安於現狀,過度依戀屬於另外一個類別內的屬性或資料時,可以稱之為「依戀情節(Feature Envy)」氣味。這個氣味代表了實現該...

鐵人賽 Software Development DAY 28

技術 Code Smell > Couplers 耦合怪

「耦合怪(Couplers)」是一種程式碼氣味的類別。這個氣味識別出將物件通通綁在一起的情況,這妨礙了在不同情境下程式碼的使用靈活性。這種高耦合阻礙了可用性和模...

鐵人賽 Software Development DAY 27

技術 Dispensables > Speculative Generality 通用畫大餅與重構

氣味的徵兆 通用畫大餅(Speculative Generality)是指當我們撰寫的程式碼是用來應對未來需求,但現實中卻可能永遠都派不上用場的這種情況。這與「...

鐵人賽 Software Development DAY 26

技術 Dispensables > Lazy Class 冗余類別與如何重構

氣味的徵兆 「冗余類別(Lazy Class)」也被稱為「遊手好閒者(Freeloader)」。當你在專案內發現存在一個無所事事的類別,幾乎沒有實作任何方法與職...

鐵人賽 Software Development DAY 25

技術 Duplicated Code > Refactoring 重構重複的程式碼

根據Joshua Kerievsky於2005年創建的「程式碼氣味到重構速查表」中,我們可以得到以下十二種對應「重複的程式碼」這種氣味的重構技巧。但如同上一篇文...

鐵人賽 Software Development DAY 24

技術 Dispensables > Duplicated Code 重複的程式碼

氣味的徵兆 重複的程式碼可能發生在多名開發者在同一個程式碼專案的不同部分同時工作時,或者當團隊的新成員在撰寫自己的新程式碼時未詳細檢查現有程式碼。會發生這種情況...

鐵人賽 Software Development DAY 23

技術 Dispensables > Dead Code 亡靈程式碼與如何重構

氣味的徵兆 在軟體開發的世界中,術語「亡靈程式碼(Dead Code)」可能含有多重定義。作為一種程式碼氣味,我們也可以將亡靈程式碼稱之為「未執行的程式碼(Un...

鐵人賽 Software Development DAY 22

技術 Dispensables > Data Class 資料類別與如何重構

氣味的徵兆 Data Class(資料類別)氣味是指當一個類別內缺乏足夠的實作功能來證明其存在意義時所出現的一種情況。它指的是一個僅包含屬性欄位和用於訪問這些資...

鐵人賽 Software Development DAY 21

技術 Dispensables > Comment 無謂的註解與重構

氣味的徵兆 「無謂的註解」是一種非常特殊的「程式碼」氣味,因為註解本身並不算是真正的程式碼。 在文章繼續之前,為了表達我對於各種不同的程式語言中最佳實踐與慣例的...

鐵人賽 Software Development DAY 20

技術 Code Smells > Dispensables 非必要的存在

「Dispensables」這個氣味分類是指程式碼中出現一些不必要的元素。如果移除它們,可以使程式碼更加乾淨、效率更高,並且更容易理解。 這個分類概念相當容易理...

鐵人賽 Software Development DAY 19

技術 Change Preventers > Parallel Inheritance Hierarchies 平行繼承的類別關係與重構

氣味的徵兆 這種氣味可以視為是「散彈槍手術(Shotgun Surgery)」的一種特例。但和散彈槍手術不同的地方在於,「平行繼承的類別關係」中我們僅只聚焦在新...

鐵人賽 Software Development DAY 18

技術 Change Preventers > Shotgun Surgery 散彈槍手術與重構

氣味的徵兆 這個程式碼氣味是我最喜歡的氣味名稱之一,因為它生動地描述了當我們試圖修改具有這種味道的程式碼時會發生什麼情況。顧名思義,就像我們朝著的程式碼射上一發...

鐵人賽 Software Development DAY 17

技術 Change Preventers > Divergent Change 發散式修改與重構

氣味的徵兆 「發散式修改(Divergent Change)」 有時候會與另一種乍看之下相似的氣味「散彈槍手術(Shotgun Surgery)」混淆,但實際上...

鐵人賽 Software Development DAY 16

技術 Code Smells > Change Preventers 變動阻礙者

經過兩週共16天的挑戰,完成了兩個氣味的介紹進入第三種氣味分類:「改變的阻礙者(Change Preventers)」。 如果我在系列文首日的文章提及,許多人不...

鐵人賽 Software Development DAY 11

技術 Code Smells > Tool Abusers 工具誤用者

前言 系列文章進入到第二個氣味類別。在完成第一個氣味分類:臃腫怪(Bloaters)的過程中,我就隱約發現一件之前一直沒有注意到的事情。就是這個「氣味對應重構」...

鐵人賽 Software Development DAY 5

技術 Bloaters > Large Class 大類別

氣味的徵兆 相似於我們上一篇所介紹的長方法(Long Method)氣味,「大類別(Large Class)」顧名思義,是指隨著時間累積,開發者不斷疊加新功能與...

鐵人賽 Software Development DAY 4

技術 Long Method > Refactoring 如何重構Long Method

(No English version yet.) 上一篇我們介紹到Long Method(長方法)的特徵與成為不良氣味(Bad Smell)的原因,接下來我們...

鐵人賽 Software Development DAY 3

技術 Bloaters > Long Method 過長的方法

(English follows Chinese) 前言 根據「Refactoring to Patterns」一書的作者Joshua Kerievsky所提供...

鐵人賽 Software Development DAY 2

技術 Code Smells > Bloaters 臃腫怪

(English follows Chinese) 首先我們來談談程式碼氣味(Code Smell)中的第一個分類:Bloaters 臃腫怪。我查了一下,華文世...

鐵人賽 Software Development DAY 1

技術 Code Smells to Refactorings

(English follows Chinese) 上次參賽已經是好幾年前,除了選題障礙之外,連續三十天的寫作對我來說早已經證實並不是太過困難的挑戰。這次恰好在...